/**
 * 在线模型处理
 *
 *  在低代码中，在线表单设计添加表字段，通常不会直接修改真实的数据库表字段，而是通过以下方式实现的：
 *  - 虚拟字段模型
 *      逻辑： 平台会会创建一个虚拟的数据结构（如JSON对象或元数据表）来描述表单字段，这些字段并非直接对应数据库中的字段，而是存储在配置文件或者专门的数据表中
 *      实现：用户通过界面自定义字段属性（如名称、类型、校验规则等），平台将其保存为配置，运行时根据这些配置动态渲染表单。
 *  - 表单与数据库的分离。
 *      逻辑：在线表单的数据和数据库之间通常通过API或者服务中间层连接，表单的字段映射到数据库字段时，开发者或平台配置决定如何映射，
 *      实现：表单字段可以和数据库字段 一一映射，也可以通过中间逻辑做字段组合转换或聚合
 *  - 动态生成和存储
 *
 *
 *  为什么不直接修改数据库表字段呢？
 *  在第代码中，不直接修改表字段的逻辑和实践考虑，为了更好滴适应灵活性，可扩展性和多样化需求，
 *  1、需求的动态性和不确定性
 *  - 动态字段
 *      用户根据业务需求，随时删除字段，如果每次都直接修改数据库表结构， 开发和维护成本会很高
 *      数据库表结构修改涉及到锁表，迁移数据库等问题，影响系统性能和稳定性。
 *  - 频繁变化
 *      表单设计需求可能频繁变化，直接修改数据库字段会导致频繁的数据库结构变更，不利于块度迭代
 *  2、提升灵活性和扩展性
 *      - 灵活应对不同表单需求
 *          通过远水配置方式，可以块度适应不同业务场景，支持多种字段类型和动态规则。
 *      - 无需为每个表单生成新表
 *          如果每个表单都直接对应数据库表，可能导致结构冗余，使用元数据可以加你不同表单共用一张数据库表。
 *  3、降低开发和维护成本
 *      - 避免复杂的数据库操作
 *          直接修改数据库字段需要复杂的迁移脚本，测试风险也高
 *      - 统一的数据管理
 *          元数据模式下，所有字段信息都存在溢出，标语管理和维护。
 *  4、提高系统稳定性
 *      - 避免锁表风险
 *          数据库表字段修改会导致锁表，可能影响系统性能，特别是对高并发的系统
 *      - 数据一致性问题
 *          修改表结构后，历史数据需要迁移，容易出错或导致系统不稳定性。
 *  5、支持无代码或第代码理念
 *      - 业务人员参与设计
 *          第代码平台的目标时让非技术人员也嫩共参与设计和使用，如果修改数据库字段、需要开发者参数，不符合低代码的设计初衷
 *      - 无代码动态扩展
 *          动态字段的实现让用户可以直接通过界面添加字段，而无需深入理解数据库
 *   6、使用多租户和多场景
 *      - 多租户系统
 *          在多租户环境中，每个租户可能有自己的字段需求，如果直接修改数据库字段，会导致表结构过于复杂或冲突。
 *          采用元数据方式，可以按租户动态生成字段，无需修改底层表结构
 *      - 跨场景复用
 *
 *
 *
 *  20251112 重新整理
 *   元数据驱动  + 混合存储（高频词 + JSONB） + 动态表/字段 + 动态 CRUD 来实现
 *
 *   为什么这么设计？
 *   1. 动态优先：低代码要让非开发人员能“随时建表建字段”，因此不能每次改字段都改代码 DDL。用元数据驱动，可以把“模型定义”变成数据，从而实现界面可配置
 */
package com.shaozj.online;